SIEMを使ってブルートフォースアタックを検知する

最近公開された IBM X-Force の「X-Force 脅威インテリジェンス・インデックス2024」にもあるように、有効なアカウントを使った初期侵害は全体の71%にもなっていて、セキュリティを考える上でアカウントログインへの監視は重要性が高いことが分かります。
アカウント資格情報の窃取を試みる攻撃のひとつとして、直接的にシステムに対してアカウントへのログイン試行を行うブルートフォースアタック（総当たり攻撃）があり、みなさんも一度は耳にしたことがあるのではないでしょうか。

また、ブルートフォースアタックにも様々手口があり以下のようなものがあげられます。

名前	内容
単純なブルートフォース	小文字と数字の簡単な組み合わせのパスワードの羅列を総当たりでログイン試行を繰り返す
パスワードリスト攻撃	辞書に載っているようなワードや一般的によく使いそうなパスワードの組み合わせに対して総当たりでログイン試行を繰り返す
ハイブリッドブルートフォース	パスワードリストの特徴に加え、単純なブルートフォースで使う簡単なパスワードの羅列を組み合わせて総当たりでログイン試行を繰り返す
リバースブルートフォース	試行するパスワードを固定して、ユーザーIDを変えてログインの試行を繰り返す。同一IDに対して複数のログイン試行が発生しないのでアカウントロック対策を回避する効果がある
クレデンシャルスタッフィング	同じユーザーIDとパスワードを使い回す習慣を悪用して、既に漏洩したユーザーIDとパスワードを用いてログイン試行を行う
レインボーテーブルアタック	漏洩したパスワードハッシュからレインボーテーブルを使って平文パスワードを復元
パスワードスプレー	試行するパスワードを固定して、複数のユーザーに対してログイン試行を行う。リバースブルートフォースと似ているが、パスワードスプレーは攻撃が遅くステルス性が高い
RDPブルートフォース	テレワークなどの環境でRDPポートが開放しているPCを狙ってID、パスワードの総当たり攻撃を行う

このように攻撃する側では色んな手段を用いて行ってきますが、痕跡や兆候を検知するには何を見たら良いでしょう。
当然、認証ログを見ることと、アカウント奪取の試みの痕跡の可能性となる認証失敗のイベントに注目することが最初のキーポイントになるかと思います。

これらの認証情報の窃取を狙った攻撃に対して、ログから検知・分析する方法を紹介していきます。

どのログを見るか

まず認証ログとは何を指すかというところですが、Windowsのローカル認証で言えばWindows Event Logのセキュリティログ、Linuxの認証の場合はSecureログ/Authログ、ドメイン認証であればActive Directoryのログ、IdPに認証を委任していればIdPのログ、SaaSで認証していればSaaSのログといったように、認証するシステムのログを取得することが必要です。

ログの何を見るか

次にログの何を見るかという点では、まず「認証失敗時のイベント」に注目します。
Windows Event Logの場合、ログオン失敗はイベントID 4625を探すことで確認することができます。
SIEMで分析するという前提だと、対象のログに対して単純にキーワード検索で*4625*という風にクエリ文を発行することで絞り込むことができます。

Splunkの場合だと、以下のようなクエリです。

（キーワード検索でログイン失敗を絞り込み）

sourcetype=WinEventLog source=WinEventLog:Security "*4625*"

キーワード検索は直感的で簡単にクエリを書けますが、検索時の効率が悪く検索に時間がかかるのと、意図せぬ文字列の一部を検索してしまうなど精度にかけてしまいます。
また、本来ならばログを絞り込んだ上でユーザー毎に集計したくなりますがキーワード検索では集計が困難な場合が多いです。

SIEMを含むデータ分析においては、特定のログの箇所をフィールドとして認識させることで検索効率と精度を上げることができ、集計も可能となります。
Splunkでは、Add-onというものが用意されており、インストールするだけでフィールドの抜き出しなどの設定を簡単に行うことができます。
Windowsの場合、Splunk Add-on for Microsoft Windows がお勧めです。

Add-onをインストールしてフィールド化できた前提でイベントID 4625で絞り、ユーザーとログオン試行した送信元で絞り込みます。

（Windows 端末のログイン失敗の多いユーザー）

sourcetype=WinEventLog source=WinEventLog:Security EventCode=4625
| stats count by user
| sort - count

さらにSplunkでは、CIM（Common Information Model）に対応していて、異なるシステム間で同じ意味を持つイベントを同じフィールドとして認識することができ、Add-onがCIM対応 *1となっている場合、CIMで定義されているフィールド *2が使えるようになっています。

（*1. 参照先リンクでは Splunk Add-on for Microsoft Windows でどのソースタイプを指定した時に、CIMのどのデータモデルに対応しているかを確認することが可能）
（*2. 参照先リンクでは CIMの各データモデルでどのフィールドに対応しているかを確認することが可能）

CIMのフィールドを利用して検索すると、以下のようにも検索することができます。

（Windows 端末のログイン失敗の多いユーザー）

sourcetype=WinEventLog source=WinEventLog:Security action=failure
| stats count by user
| sort - count

アドホックな分析以外に可視化しておくことで、ダッシュボードから異常なデータに気づくことができます。
この場合だと円グラフで可視化が良さそうです。

その他にLinuxの認証ログも同じように見ていくことにします。
Linuxでは、Splunk Add-on for Unix and Linux のAdd-onをインストールするとフィールドを自動認識してくれます。

Linuxの場合、pam(Pluggable Authenticaton Modules) という認証システムが利用されることが多いですが、SSHによるログインやスーパーユーザーへのアカウントスイッチも同じログ内に非構造化データとして出力されます。
以下、ログの一例です。

（Secure/Authログの例）

Apr 12 12:33:08 acmepayroll sshd[13505]: Accepted password for root from 71.239.187.4 port 1390 ssh2

Apr 16 12:40:44 acmefileserver su[2269]: pam_unix(su:session): session opened for user root by jack.bauer(uid=0)

先程のWindowsと同じようにLinuxのAdd-onはCIMに対応しているため、以下のように検索することができます。

（Linux 端末のログイン失敗の多いユーザー）

sourcetype="linux_secure" action=failure
| stats count by user
| sort - count

こちらも可視化しておくことで全体を見ることができます。

Windows、Linuxのログまとめてみたい時は、ログソースを複数指定して検索することも可能です。

（Windows 端末、Linux 端末でログイン失敗の多いユーザー）

(sourcetype=WinEventLog source=WinEventLog:Security) OR sourcetype=linux_secure action=failure
| stats count by user
| sort - count

また、ユーザー起点だけでなく、送信元起点で失敗の多い送信元を検索することでブルートフォースに関するセキュリティのインサイトを高めることができます。

（Windows 端末、Linux 端末でログイン失敗の多い送信元）

(sourcetype=WinEventLog source=WinEventLog:Security) OR sourcetype=linux_secure action=failure
| stats count by src
| sort - count

さらに、時系列データにしてホストごとの失敗数の推移を見るとどの時点でイベントが多く発生しているのかスパイクが見ることができます。

（Windows 端末、Linux 端末でログイン失敗の多い数 - ホストごと）

(sourcetype=WinEventLog source=WinEventLog:Security) OR sourcetype=linux_secure action=failure user=* user!=""
| timechart count by host

時系列データは折れ線グラフや縦棒グラフにしておくとどのタイミングでデータが変動しているのか分かりやすくなります。

さらに、ログイン成功と失敗の割合を分析することでブルートフォース攻撃の可能性を判断するのに有効に活用できます。

（Windows 端末、Linux 端末でログイン成功をもとにしたログイン失敗の割合）

(sourcetype=WinEventLog source=WinEventLog:Security) OR sourcetype=linux_secure user=* user!=""
| stats count(eval(action="success")) as successes count(eval(action="failure")) as failures by user
| eval perc_failures_to_total = round((100*failures) / (failures + successes), 2)
| sort - perc_failures_to_total failures

少しだけクエリが複雑になってきたので、かいつまんでクエリの意味を補足しておきます。

| stats count(eval(action="success")) as successes count(eval(action="failure")) as failures by user

successesフィールドを新規に作成し、ユーザーごとにactionが「success」のレコードをカウントした結果を格納、failuresフィールドを新規に作成し、ユーザーごとにactionが「failure」のレコードをカウントした結果を格納します。

| eval perc_failures_to_total = round((100*failures) / (failures + successes), 2)

perc_failures_to_totalフィールドを新規に作成し、パーセント表示でログイン失敗の割合を格納します。

その結果、ユーザー毎にログイン失敗の割合を分析することができるようになっています。

ダッシュボード化する

作成したクエリをダッシュボード化しておくと、日々の運用で異常なアクティビティがないか監視することができます。

Windowsの認証ログに対しては、「端末のログイン失敗の多いユーザー」、「端末のログイン失敗の多い送信元」、「Windows 端末でログイン失敗の多い数 - ホストごと」をそれぞれ可視化しています。

Linuxの認証ログに対しても同じく、「端末のログイン失敗の多いユーザー」、「端末のログイン失敗の多い送信元」、「Linux 端末でログイン失敗の多い数 - ホストごと」をそれぞれ可視化しています。

認証ログ全体でも同じく、「端末のログイン失敗の多いユーザー」、「端末のログイン失敗の多い送信元」、「Windows 端末、Linux 端末でログイン失敗の多い数 - ホストごと」をそれぞれ可視化しています。

そして認証ログ全体での「Windows 端末、Linux 端末でログイン成功をもとにしたログイン失敗の割合」を可視化しました。

これらの可視化データを分析したり、さらにSIEMの検索機能を使ってドリルダウンしていくことで、システムを横断したログからのブルートフォース攻撃の検知ができるようになりました。

まとめ

今回は、セキュリティで重要な攻撃起点となる認証情報の窃取を狙ったブルートフォース攻撃に焦点を当ててユースケースを紹介しました。
攻撃をされない仕組みや攻撃を防ぐ仕組みを強化するのも重要ですが、攻撃に気づく仕組みを整理することも大切です。
ログ分析のユースケースを増やして発見的対策を強化していきたいですね。